packages/ui/components/form/inputs/Input.tsx (1)

47-51: Minor accessibility trade-off with tabIndex={-1}.

Adding tabIndex={-1} removes the password visibility toggle from the tab order. This simplifies form navigation but means keyboard-only users cannot toggle password visibility without a mouse. This is a common pattern, but worth noting that it reduces keyboard accessibility.

apps/web/pages/api/auth/two-factor/totp/setup.ts (1)

60-61: Consider hashing backup codes instead of encrypting them.

Backup codes only need to be verified, not decrypted. Hashing each code individually (e.g., with bcrypt or scrypt) would provide stronger security — if the encryption key is compromised, encrypted backup codes are immediately exposed, whereas hashed codes remain protected.

That said, this follows the same symmetric encryption pattern already used for twoFactorSecret in this codebase, so it's consistent.

apps/web/components/settings/TwoFactorAuthAPI.ts (1)

22-25: Consider making backupCode optional.

The UI is mutually exclusive—users provide either a TOTP code or a backup code, not both. Currently, one value is always an empty string. Making backupCode optional and conditionally including it in the request body would better express intent and avoid unnecessary empty parameters:

♻️ Suggested change

-  async disable(password: string, code: string, backupCode: string) {
+  async disable(password: string, code: string, backupCode?: string) {
     return fetch("/api/auth/two-factor/totp/disable", {
       method: "POST",
-      body: JSON.stringify({ password, code, backupCode }),
+      body: JSON.stringify({ password, code, ...(backupCode && { backupCode }) }),

apps/web/playwright/login.2fa.e2e.ts (1)

12-13: TODO noted: add backup code login and disable tests.

The comment on line 12 calls out missing test scenarios for logging in with a backup code and disabling 2FA with a backup code. These are important paths given the new feature. Consider tracking this as a follow-up issue.

Would you like me to open a GitHub issue to track the missing backup-code test scenarios (login with backup code, disable 2FA with backup code)?

apps/web/pages/api/auth/two-factor/totp/disable.ts (1)

46-64: Duplicated backup-code validation logic — extract a shared helper.

The decrypt → parse → indexOf → invalidate flow here (lines 48–64) is nearly identical to the one in next-auth-options.ts (lines 131–156). Both decrypt backup codes, strip dashes, look up the code, and handle the same error cases. This duplication means any future fix (e.g., adding JSON.parse error handling) must be applied in both places.

Consider extracting a shared utility, e.g., validateBackupCode(encryptedCodes, suppliedCode, encryptionKey), that both call sites can use.

Also, JSON.parse on line 58 will throw an unhandled exception if the decrypted payload is malformed — same concern flagged in next-auth-options.ts.

apps/web/pages/auth/login.tsx (2)

73-80: Backup code errors handled outside the errorMessages map — inconsistent pattern.

IncorrectBackupCode and MissingBackupCodes are handled inline (lines 157–158) while all other credential errors go through the errorMessages object (lines 73–80). This makes the error handling less discoverable.

Proposed refactor

   const errorMessages: { [key: string]: string } = {
     // [ErrorCode.SecondFactorRequired]: t("2fa_enabled_instructions"),
     // Don't leak information about whether an email is registered or not
     [ErrorCode.IncorrectEmailPassword]: t("incorrect_email_password"),
     [ErrorCode.IncorrectTwoFactorCode]: `${t("incorrect_2fa_code")} ${t("please_try_again")}`,
     [ErrorCode.InternalServerError]: `${t("something_went_wrong")} ${t("please_try_again_and_contact_us")}`,
     [ErrorCode.ThirdPartyIdentityProviderEnabled]: t("account_created_with_identity_provider"),
+    [ErrorCode.IncorrectBackupCode]: t("incorrect_backup_code"),
+    [ErrorCode.MissingBackupCodes]: t("missing_backup_codes"),
   };

Then remove the dedicated else if branches on lines 157–158 — the fallback on line 160 (errorMessages[res.error]) will handle them.

Also applies to: 157-158

---

221-221: Nested ternary is hard to scan.

This line has two nested ternaries. Consider restructuring for readability, though it's functionally correct.

Suggested alternative

-              {twoFactorRequired ? !twoFactorLostAccess ? <TwoFactor center /> : <BackupCode center /> : null}
+              {twoFactorRequired && (
+                twoFactorLostAccess ? <BackupCode center /> : <TwoFactor center />
+              )}

apps/web/components/settings/EnableTwoFactorModal.tsx (3)

71-75: resetState should clear sensitive data (backup codes) from state.

When the user cancels or closes the modal, resetState resets password, errorMessage, and step but leaves backupCodes and backupCodesUrl in memory. Since backup codes are security-sensitive, clear them on reset to minimize exposure.

Proposed fix

  const resetState = () => {
    setPassword("");
    setErrorMessage(null);
    setStep(SetupStep.ConfirmPassword);
+   setBackupCodes([]);
+   if (backupCodesUrl) URL.revokeObjectURL(backupCodesUrl);
+   setBackupCodesUrl("");
  };

---

163-163: Nit: formatBackupCode is a pure function — extract outside the component.

It has no dependency on component state or props, so it's recreated every render unnecessarily.

Proposed refactor

Move the function definition above the component:

+const formatBackupCode = (code: string) => `${code.slice(0, 5)}-${code.slice(5, 10)}`;
+
 const EnableTwoFactorModal = ({ onEnable, onCancel, open, onOpenChange }: EnableTwoFactorModalProps) => {
   ...
-  const formatBackupCode = (code: string) => `${code.slice(0, 5)}-${code.slice(5, 10)}`;

---

174-182: Nit: type="password" is redundant on PasswordField.

PasswordField typically renders a password input by default. The explicit type="password" prop is harmless but unnecessary.